Lightweight Directory Access Protocol (LDAP) is a well known standard defined by Internet Engineering Task Force (IETF) to enable server computers to provide directory services to client computers. The client computers may contain various application programs such as an email tool which makes a TCP/IP connection to an LDAP server computer, to look up entries maintained in a directory by the LDAP server. Each entry in such a directory contains information (such as a URL) about an object (such as a file). Each entry in the directory has several attributes, and each attribute has a particular syntax which identifies the types of values that can be associated therewith. Syntax definition for attributes in the Lightweight Directory Access Protocol may conform to a standards document called RFC 2252 which is available at the following website (wherein “%” should be replaced by “/” and “-” replaced by “.”):
http:%%www-ietf-org%rfc%rfc2252-txt.
Note that this format for URLs is followed throughout this patent application. Some attribute types are defined by the International Telecommunication Union (ITU-T) in # ITU-T Recommendation X.520-Information Technology-Open Systems Interconnection-The Directory: Selected attribute types. In order to create an LDAP directory, it is common for a human to design objects and attributes, which form a schema. See, for example, an article entitled “LDAP Schema Design” by Andrew Findlay, February 2005. Such an LDAP schema can be expressed in human-readable form, in a format called LDAP Data Interchange Format (LDIF) as described in a standards document called RFC 2849 which is available at the following website (wherein “%” should be replaced by “/” and “-” replaced by “.”):
http:%%www-ietf-org%rfc%rfc2849-txt
LDIF is typically used to import and export information to/from an LDAP directory. The LDIF format can also be used to describe a set of changes which are to be applied to an LDAP directory. LDIF can further be used for bulk loading of data. For additional information on using LDIF see a document available at the following website (wherein “%” should be replaced by “/” and “-” replaced by “.”):
http:%%www-zytrax-com%books%Idap%ch8
Although the LDIF format is human readable, it has a very specific syntax and grammar which cannot be directly parsed by tools that handle Extensible Markup Language (XML) documents, such as a browser. For example, LDIF uses special characters such as a hash sign “#”, a comma “,”, a plus sign “+”, a backslash “\” and a semicolon “;” to have a specific meaning when used an LDIF document. In order to use XML tools, the information in an LDIF document can be expressed in a variant of XML defined by The Organization for the Advancement of Structured Information Standards (OASIS), which is called Directory Service Markup Language (DSML). Currently, DSML has two specifications: a first specification DSMLv1 that can be used to represent the state of a directory, and a second specification DSMLv2 that can be used to represent operations an LDAP directory can perform and the results of such operations. More information on DSML can be found at the following website for OASIS (wherein “%” should be replaced by “/” and “-” replaced by “.”):
http:%%www-oasis&open-org%specs%index-php#dsmlv2
Note that in the above URL, the “&” should be replaced by “-”. The approach of DSML, as defined in this OASIS standard, is not to abstract the capabilities of LDAP directories, but instead to faithfully represent LDAP directories in XML.
Hence, even though DSML is a form of XML, it appears to so closely follow LDAP that it is necessary for humans writing this variant of XML to have some knowledge of LDAP. Specifically, even if a human is creating a schema for a directory using an XML editing tool (and this human is hereinafter XML developer) they still need to know some aspects of LDAP. For example, the XML developer must know that LDAP names are fully qualified, i.e. start from the root rather than relative names. As another example, the XML developer must supply an identifier for each attribute, and ensure that the identifier remains globally unique over the lifetime of the product. As yet another example, the XML developer must identify a type for each attribute to be one of structural, abstract and auxiliary as per the LDAP. Inventors of the invention described below believe that requiring the XML developer to know LDAP makes it difficult to use an LDAP server for most applications because most XML developers are not familiar with LDAP.